O DCOM95 oferece suporte COM distribuφdo para Microsoft(r) Windows(r) 95.
O protocolo de cabo DCOM oferece suporte, de forma transparente, para a comunicaτπo confißvel, segura e eficiente entre componentes do Component Object
Model (COM, modelo de objeto componente), como controles ActiveX(r), scripts e
miniaplicativos Java que residem em mßquinas diferentes em uma LAN (Local Area Network, rede local), uma WAN (Wide Area Network, rede remota) ou na Internet. Com o DCOM, seu aplicativo pode ser distribuφdo atravΘs de locais mais significativos para seu cliente e para o aplicativo.
Para obter informaτ⌡es mais aprofundadas, consulte a Visπo tΘcnica geral do DCOM disponφvel na home page do Microsoft COM, em http://www.microsoft.com/com/.
Conte·do
========
I. Novos recursos
II. Soluτ⌡es de erros
III. Problemas conhecidos
IV. Diferenτas do DCOM no Windows NT
V. Redistribuiτπo
VI. Suporte e recursos
VII. Listagem de arquivos
I. Novos recursos
-----------------
Substituindo o DCOM95 pela versπo anterior proibida
Nas vers⌡es anteriores do DCOM95, era possφvel substituir uma versπo mais recente do DCOM95 por uma versπo anterior dele. Agora, os n·meros da versπo sπo verificados na instalaτπo e vocΩ nπo pode instalar uma versπo anterior sobre uma versπo mais recente. Esta alteraτπo evitarß problemas com vers⌡es incompatφveis de DLLs (Dynamic Link Library, biblioteca de vφnculo dinΓmico).
Suporte de monitoraτπo de processo do Visual Studio 6.0
Em suporte ao Visual Studio 6.0, o DCOM95 fornece informaτ⌡es de monitoraτπo para desenvolvedores, para ajudß-los a entender o comportamento, desempenho e estrutura do aplicativo. Se vocΩ estiver usando o Visual Studio Analyzer em um computador que esteja executando o Windows 95, deverß usar sempre esta versπo do DCOM95.
Nova pasta criada pelo Programa de Instalaτπo
O Programa de Instalaτπo cria uma pasta chamada DCOM95 na pasta do sistema. O contrato de licenτa de usußrio final e outros arquivos sπo armazenados aqui. O Programa de Instalaτπo tambΘm cria um subdiret≤rio do DCOM95 chamado
OLDOLE, no qual Θ feito backup do DCOM95 anterior ou dos binßrios OLE. Esses arquivos serπo restaurados se vocΩ desinstalar o DCOM95.
COM Internet Services
O COM Internet Services (CIS) permite que clientes e servidores sejam conectados atravΘs da Internet usando o COM. O CIS consiste em
* Um novo protocolo DCOM, TCP encapsulado
* Um novo tipo de identificador de origem, identificador de origem OBJREF
* Um novo utilitßrio CISCNFG
Para suporte a cliente CIS no Windows 95, vocΩ deve instalar o DCOM95 e o DCOMCFG. Em seguida, use a ferramenta CISCNFG, que Θ instalada durante a instalaτπo do utilitßrio de configuraτπo DCOM, para alterar a chave do Registro que define o protocolo a ser usado para processos remotos. Na janela Prompt de comando, digite:
ciscnfg <protocol>
Onde <protocol> Θ:
* rpc para usar RPC (Remote Procedure Call, chamada de procedimento remoto)
* http para usar HTTP (Hypertext Transfer Protocol, protocolo de transferΩncia de hipertexto)
* tcp_http para tentar primeiro o TCP e, em seguida, se o tempo-limite do servidor expirar, tentar o HTTP.
O comando ciscnfg sem argumentos fornece informaτ⌡es sobre o uso.
Nπo Θ necessßria nenhuma atualizaτπo do SDK para usar o protocolo TCP encapsulado.
Hß poucas atualizaτ⌡es para identificadores de origem OBJREF.
CreateObjrefMoniker
Cria um identificador de origem OBJREF baseado em um ponteiro para um objeto.
WINOLEAPI CreateObjrefMoniker(
LPUNKNOWN pUnk, //Ponteiro para o objeto
LPMONIKER *ppMk //Endereτo do ponteiro para o identificador de origem OBJREF
);
ParΓmetros
pUnk
Ponteiro para a interface IUnknown no objeto que o identificador de origem irß representar.
ppMk
Endereτo de um ponteiro para a interface IMoniker no identificador de origem OBJREF criado.
Valores retornados
Esta funτπo dß suporte aos valores retornados padrπo
E_OUTOFMEMORY e E_UNEXPECTED, alΘm do seguinte:
S_OK
O identificador de origem OBJREF foi criado com Ωxito.
Comentßrios
Os clientes usam identificadores de origem OBJREF para obterem um ponteiro empacotado para um objeto em execuτπo no espaτo de endereτo do servidor.
O servidor geralmente chama CreateObjrefMoniker para criar um identificador de origem OBJREF e, em seguida, chama IMoniker::GetDisplayName e, finalmente, libera o identificador de origem. O nome para exibiτπo para um identificador de origem OBJREF tem o formato:
OBJREF:nnnnnnnn
Onde nnnnnnnn Θ uma codificaτπo de base 64 arbitrariamente longa que encapsula o local da mßquina, a extremidade do processo e a identificaτπo do ponteiro de interface (IPID) do objeto em execuτπo.
Em seguida, o nome para exibiτπo pode ser transferido para o cliente como texto. Por exemplo, o nome para exibiτπo pode residir em uma pßgina HTML cujo download Θ feito pelo cliente.
O cliente pode passar o nome para exibiτπo para MkParseDisplayName, que cria um identificador de origem OBJREF baseado no nome para exibiτπo. Em seguida, uma chamada para o mΘtodo IMoniker::BindToObject do identificador de origem obtΘm um ponteiro empacotado para a ocorrΩncia em execuτπo no servidor. Por exemplo, um componente COM do servidor contido em um Active Server Page pode criar um identificador de origem OBJREF, obter seu nome para exibiτπo e gravar o nome para exibiτπo na saφda para HTML que Θ enviada ao navegador cliente. Um script executado no cliente usa o nome para exibiτπo para obter acesso ao objeto em execuτπo. Um script do Visual Basic do cliente, por exemplo, poderia armazenar o nome para exibiτπo em uma varißvel chamada strMyName e incluir esta linha:
objMyInstance = GetObject(strMyName)
O motor de script faz internamente as chamadas para MkParseDisplayName e IMoniker::BindToObject e, em seguida, o script pode usar objMyInstance para referir-se diretamente ao objeto em execuτπo.
Se o objeto em execuτπo usar IPIDs estßticos e o processo do s
IMoniker::BindToObject. Para identificadores de origem OBJREF, o parΓmetro pmkToLeft deve ser NULL. Como o identificador de origem OBJREF representa um objeto em execuτπo, nπo ocorre nenhuma ativaτπo. Se o objeto representado nπo estiver mais em execuτπo, o BindToObject falharß com E_UNEXPECTED.
IMoniker::BindToStorage. Este mΘtodo obtΘm um ponteiro empacotado para a interface solicitada no armazenamento que contΘm o objeto em execuτπo. Como o identificador de origem OBJREF representa um objeto em execuτπo, nπo ocorre nenhuma ativaτπo. Se o objeto representado nπo estiver mais em execuτπo, o BindToStorage falharß com E_UNEXPECTED.
IMoniker::Reduce. Este mΘtodo retorna
MK_S_REDUCED_TO_SELF e passa de volta o mesmo identificador de origem.
IMoniker::ComposeWith. Se pmkRight for um antiidentificador de origem, o identificador de origem retornado serß NULL. Se pmkRight for um composto cujo componente α esquerda Θ um antiidentificador de origem, o identificador de origem retornado serß o composto com o antiidentificador de origem α esquerda removido. Se pmkRight nπo for nem um antiidentificador de origem nem um identificador de origem composto cujo componente α esquerda Θ um antiidentificador de origem, o mΘtodo verificarß o parΓmetro fOnlyIfNotGeneric. Se for FALSE, o mΘtodo combinarß os dois identificadores de origem em um composto genΘrico; se for TRUE, o mΘtodo definirß *ppmkComposite como NULL e retornarß MK_E_NEEDGENERIC.
IMoniker::Enum. Este mΘtodo retorna S_OK e define
ppenumMoniker como NULL.
IMoniker::IsEqual. Este mΘtodo retorna S_OK se *pmkOther for um identificador de origem OBJREF e o caminho para ambos os identificadores de origem for idΩntico
(usando uma comparaτπo que nπo coincide mai·sculas e min·sculas). Caso contrßrio, o mΘtodo retornarß S_FALSE.
IMoniker::Hash. Este mΘtodo calcula um valor hash para o identificador de origem.
IMoniker::IsRunning. Como os identificadores de origem OBJREF representam uma instΓncia do objeto em execuτπo, este mΘtodo retornarß TRUE a menos que o objeto nπo esteja mais em execuτπo devido a uma falha de chamada recente. O mΘtodo ignora pmkToLeft.
IMoniker::GetTimeOfLastChange. Este mΘtodo retorna
E_NOTIMPL.
IMoniker::Inverse. Este mΘtodo retorna um antiidentificador de origem (isto Θ, os resultados da chamada de CreateAntiMoniker).
IMoniker::CommonPrefixWith. Se os dois identificadores de origem forem iguais, este mΘtodo retornarß MK_S_US e definirß *ppmkPrefix como NULL. Se o outro identificador de origem nπo for um OBJREF, este mΘtodo passarß ambos os identificadores de origem para a funτπo MonikerCommonPrefixWith. Esta funτπo lida corretamente com o caso em que o outro identificador de origem Θ um composto genΘrico.
Se nπo houver um prefixo comum, este mΘtodo retornarß MK_E_.
IMoniker::RelativePathTo. Este mΘtodo retorna E_NOTIMPL.
IMoniker::GetDisplayName. Este mΘtodo obtΘm o nome para exibiτπo do identificador de origem OBJREF. O nome para exibiτπo Θ uma codificaτπo de 64 bits que encapsula o local da mßquina, o ponto de extremidade do processo e a identificaτπo do ponteiro de interface (IPID) do objeto em execuτπo. Para compatibilidade futura, o nome para exibiτπo estß restrito a caracteres que podem ser especificados como parte de um URL.
IMoniker::ParseDisplayName. Se pmkToLeft nπo for NULL, este mΘtodo retornarß MK_E_SYNTAX.
IMoniker::IsSystemMoniker. Este mΘtodo retorna S_OK e passa de volta MKSYS_OBJREFMONIKER.
Suporte para tipos de dados VB6.0
O Visual Basic(r) 6.0 permite que variaτ⌡es do Visual Basic contenham estruturas de dados definidas pelo usußrio. Agora, o DCOM95 dß suporte α remoτπo dessas variaτ⌡es.
II. Soluτ⌡es de erros
---------------------
Race ao descarregar vßrios m≤dulos
Quando vßrios m≤dulos eram descarregados simultaneamente, ocorria um race nas vers⌡es anteriores do DCOM95. Dependendo da ordem em que os m≤dulos eram descarregados, poderia ocorrer uma violaτπo de acesso. Isso foi corrigido nesta versπo do DCOM95.
┴rea de trabalho que nπo responde durante negociaτ⌡es do protocolo RPC
As vers⌡es anteriores do DCOM95 nπo enviavam mensagens enquanto estivessem negociando protocolos RPC. Em certos casos, se o usußrio tivesse iniciado outro aplicativo enquanto os protocolos RPC estavam sendo negociados, a mßquina poderia parecer inativa. Ap≤s 30 segundos, o processamento de mensagens continuaria. Este comportamento foi alterado na versπo mais recente do DCOM95 e os aplicativos podem ser iniciado enquanto os protocolos RPC estπo sendo negociados.
┴rea de trabalho sem resposta quando um novo aplicativo Θ iniciado
O RPC cria uma janela oculta no Multiple-Threaded Apartment (MTA),
que nπo Θ necessßria para enviar mensagens por espec. DCOM.
Quando um usußrio inicia um novo aplicativo a partir da ßrea de trabalho, o Windows envia uma mensagem para todos os outros identificadores de janela, notificando-os deste evento e aguardando uma resposta. Nas vers⌡es mais recentes do DCOM95, talvez a janela do RPC oculta nπo responda e o Windows seja desligado. Esta versπo do DCOM95 corrige este problema e a janela do RPC nπo deixa mais a ßrea de trabalho sem resposta quando novos aplicativos sπo iniciados.
Mem≤ria corrompida com vßrios endereτos IP
Em certos casos, se vocΩ estiver executando uma versπo anterior do
DCOM95 em uma mßquina com mais de um endereτo IP, o buffer do endereτo IP ficaria saturado e a mem≤ria seria corrompida. Isso foi corrigido na versπo mais recente do DCOM95.
Uso apenas do primeiro endereτo IP
Se vocΩ estiver executando uma versπo anterior do DCOM95 em uma mßquina com duas placas de adaptador de rede (e, portanto, dois endereτos IP, cada um atribuφdo a um cartπo de visita diferente), o DCOM95 usarß somente um adaptador de rede. Nesta versπo do DCOM95, se o primeiro adaptador de rede tentado nπo funcionar, serß usado o segundo.
O RPC agora tenta vßrios endereτos IP
Ao fazer uma chamada de procedimento remoto para uma mßquina com vßrios endereτos IP, os endereτos IP subseqⁿentes serπo tentados agora se a conexπo com o primeiro falhar.
Os identificadores de origem de arquivo dπo suporte α sintaxe de caminho adicional
Os identificadores de origem de arquivo agora podem ser criados sem os argumentos do formulßrio <startdir><relativepath>, como "C:\bug\bug\..\..\foo.jpg." No DCOM95 1.1, somente os caminhos relativos (p.ex., "..\..\foo.jpg") ou caminhos absolutos (p.ex., "C:\foo.jpg") eram permitidos.
Falha de proteτπo geral quando o Oleaut32.dll Θ descarregado
Nas vers⌡es anteriores do DCOM95, ocorria uma falha de proteτπo geral
quando o Oleaut32.dll era descarregado antes de uma chamada para CoUninitialize. Isso ocorreria com mais freqⁿΩncia quando um aplicativo VB criava um controle
estatisticamente vinculado ao Oleaut32.dll e, em seguida liberava o controle antes de chamar o CoUninitialize. Isso nπo causa mais uma falha de proteτπo geral na versπo mais recente do DCOM95.
Empacotamento e desempacotamento de tipos do Visual Basic
O empacotamento e desempacotamento de certos tipos de dados do Visual Basic
foi corrigido. Agora, os parΓmetros de matriz com tamanho maior que 64K
sπo permitidos. As estruturas definidas usando aliases para o tipo agora sπo
empacotadas e desempacotadas corretamente.
┴tomos sendo excluφdos vßrias vezes no OleUninitialize
Este erro aparecia nos aplicativos que chamavam o OleInitialize e
OleUninitialize vßrias vezes. Durante a inicializaτπo, o OLE adiciona
muitos ßtomos para o RPC de DDE (Dynamic Data Exchange, intercΓmbio dinΓmico
de dados). Se os ßtomos jß tiverem sido adicionados por outro segmento,
eles nπo serπo adicionados novamente. No entanto, durante a desinicializaτπo,
os ßtomos sempre eram excluφdos e os identificadores nπo eram anulados. Portanto, na pr≤xima vez em que o OleInitialize fosse chamado, os antigos identificadores ainda existiriam, mesmo que os ßtomos jß tivessem sido
excluφdos e o OLE nπo os adicionaria novamente. Isso fazia com que todos os ßtomos OLE tornassem-se invßlidos ap≤s vßrias chamadas para OleInitialize e
OleUninitialize. Este problema foi corrigido nesta versπo do DCOM95.
Servidores ADO sπo desligados corretamente
Os Active Data Objects (ADOs) usam identificadores de origem do ponteiro para
iniciar um processo do servidor. As vers⌡es anteriores do DCOM95 continham um erro envolvendo a contagem de referΩncia do identificador de origem do ponteiro, por meio do qual os identificadores de origem do ponteiro eram criados com uma contagem de referΩncia inicial igual a 1, em vez de 0. Portanto, a contagem de referΩncia do identificador de origem do ponteiro nunca seria zero e o identificador de origem do ponteiro nunca seria liberado. Como resultado, os servidores ADO nunca eram desligados, mesmo depois da liberaτπo do ·ltimo
ponteiro para eles. Isso foi corrigido nesta versπo do DCOM95.
O CoCreateInstance funciona com nome DNS (Domain Name System, sistema de nomes de domφnios) pr≤prio
Nas vers⌡es anteriores do DCOM95, chamar o CoCreateInstance com o nome totalmente
qualificado da mßquina local nπo funcionava. Isso foi corrigido na versπo atual
do DCOM95 e, agora, o CoCreateInstance cria corretamente uma ocorrΩncia na
mßquina local.
Confirmaτπo lenta no armazenamento-raiz com arquivo composto muito grande
Nas vers⌡es anteriores do DCOM95, o tempo de confirmaτπo em um armazenamento-raiz aberto no modo STGM_TRANSACTED tornava-se muito lento conforme o arquivo composto tornasse-se muito grande (p.ex., 400M). Os limites internos da pßgina da tabela foram aumentados e isso nπo representa mais um problema.
Exportando objetos a partir de um MTA recriado
Nas vers⌡es anteriores do DCOM95, um servidor nπo podia exportar um
objeto a partir de um Multi-Threaded Apartment (MTA) se nπo fosse a primeira vez que o MTA havia sido criado no processo. Isso foi corrigido. Agora, se um servidor criar um MTA, destruφ-lo e recriß-lo subseqⁿentemente, os objetos poderπo ser exportados a partir do MTA.
Vßrias ocorrΩncias de EXEs do Visual Basic 4
No DCOM95 v1.1, se vocΩ iniciasse vßrias ocorrΩncias do mesmo executßvel do
Visual Basic 4 e, em seguida, as desativasse em qualquer ordem exceto
LIFO (Last-In First-Out, ·ltimo a entrar, primeiro a sair), o ·ltimo seria deslocado. Isso tambΘm era verdadeiro em relaτπo aos formulßrios E do
Microsoft Exchange. Isso foi corrigido no versπo mais recente do DCOM95. Agora, vocΩ pode desativar os exes do Visual Basic 4 em qualquer ordem.
Caracteres estendidos nos nomes de arquivo do Visual Basic
Se vocΩ nomeou um m≤dulo ou classe do Visual Basic usando caracteres estendidos
para um determinado idioma, talvez esse arquivo nπo seja aberto em mßquinas
configuradas para um local diferente. Isso foi corrigido.
III. Problemas conhecidos
-------------------------
Corel WordPerfect Suite 7: Instalaτπo causa falha de pßgina invßlida
Se vocΩ instalar o Corel WordPerfect Suite 7 em um sistema Windows 95
que esteja executando o DCOM95, poderß obter uma falha de pßgina invßlida no
PfOd70.pfc durante a instalaτπo. Se este erro aparecer, feche a caixa de dißlogo
da mensagem de erro. O Programa de Instalaτπo deve continuar com Ωxito.
Microsoft Access95: Replicaτπo de banco de dados nπo funciona
Se vocΩ tentar replicar um banco de dados do Access usando o Microsoft Access
95 em mßquinas com o DCOM95 instalado, poderß obter a seguinte mensagem de erro:
O Microsoft Access nπo pode concluir esta operaτπo por nπo poder localizar ou inicializar a biblioteca de vφnculo dinΓmico Msjtrclr.
Este Θ um problema do Microsoft Access 95. VocΩ pode contornar este problema gravando um programa que usa o modelo de objeto do Access em vez da ferramenta de rΘplica, ou usando o porta-arquivos para replicaτπo. O Microsoft Access 97 nπo Θ afetado por este problema.
WordPerfect
Se vocΩ tiver um documento do WordPerfect contendo uma planilha do
Corel incorporada e a planilha contiver outro objeto incorporado (por exemplo, um bitmap), vocΩ poderß obter um dißlogo de aviso dizendo que a conexπo com a rede foi perdida quando vocΩ fechou o objeto mais interno. Pode haver quatro ou cinco avisos como esse. Todos esses avisos sπo favorßveis. Basta fechß-los e continuar.
Os clientes do Multiple-threaded apartment (MTA) que usam rotinas de conversπo BSTR podem bloquear mensagens do DDE
As rotinas de conversπo BSTR de automaτπo (por exemplo, BstrFromR4)
criam janelas ocultas para facilitar a conversπo de tipo. Essas janelas nπo atendem α fila de mensagens do Windows. Se for criada uma janela desse tipo a partir de um cliente MTA, as mensagens do DDE poderπo ser bloqueadas. O segmento cliente nπo tem a obrigaτπo de atender α fila de mensagens sob o modelo de programaτπo do MTA. Se isso nπo ocorrer, esta janela de nφvel superior farß com que as mensagens de transmissπo global sejam bloqueadas.
Hß duas maneiras de contornar esta situaτπo. Chame as rotinas de conversπo
BSTR a partir de um cliente single-threaded apartment (STA) ou fazer com que o segmento MTA do cliente comporte-se como um segmento STA (um segmento STA deve atender α fila de mensagens). Se o segmento estiver bloqueando em um identificador win32, ele deverß chamar a funτπo MsgWaitForMultipleObjects para enviar mensagens do Windows.
Os nomes de caminho de DLL com mais de 127 caracteres causam erro
Se vocΩ registrar uma DLL com um nome de caminho de 128 caracteres ou mais, o registro serß bem-sucedido, mas CoCreateInstance ou CoGetClassObject
retornarπo um erro (REGDB_E_CLASSNOTREG) ao acessarem um objeto para a qual esta DLL oferece suporte.
IV. Diferenτas do DCOM no Windows NT
-------------------------------------
Recursos de seguranτa do DCOM95
A funcionalidade principal e a application programming interface (API, interface de programaτπo de aplicativo)para DCOM95 sπo idΩnticas tanto no Windows 95 quanto no Windows NT 4.0/5.0. No entanto, determinados recursos relacionados αs infra-estruturas de seguranτa sπo diferentes devido αs diferentes infra-estruturas de seguranτa dos sistemas operacionais. O uso das configuraτ⌡es de seguranτa padrπo do sistema Θ recomendßvel; tambΘm Θ necessßrio ativar a seguranτa em nφvel de usußrio nos compartilhamentos do sistema de arquivos. (Veja abaixo.)
Estπo disponφveis os seguintes serviτos, que podem ser usados para sobrescrever a seguranτa padrπo:
* CoInitializeSecurity
* CoQueryAuthenticationService
* CoQueryProxyBlanket
* CoSetProxyBlanket
* CoQueryClientBlanket
* Interface IClientSecurity
* Interface IServerSecurity
No entanto, certos recursos que fazem parte do DCOM para Windows
NT nπo estarπo disponφveis no Windows 95 devido αs diferenτas na infra-estrutura de seguranτa no Windows 95.
Particularmente, a falta de funτ⌡es de seguranτa na API do Win32, como a capacidade de criar access control lists (ACLs, listas de controle de acesso) e a funτπo AccessCheck, bem como a falta de um contexto de seguranτa associado a sφmbolos do segmento e do processo, devem ser levados em conta. O Windows 95 nπo dß suporte em modo nativo a essas funτ⌡es ou instruτ⌡es. Por este motivo, o DCOM95 nπo darß suporte α personificaτπo(especificamente, αs funτ⌡es auxiliares CoImpersonateClient e CoRevertToSelf atravΘs da interface IServerSecurity), que Θ baseada na seguranτa de sφmbolo do segmento e do processo no Windows NT 4.0. A personificaτπo geralmente Θ usada para controlar automaticamente o acesso a recursos do sistema restritos, como o sistema de arquivos, outros processos e a rede. Esses recursos nπo sπo restritos no Windows 95.
No entanto, o DCOM95 oferece aos programadores vßrios objetos auxiliares para fornecer a funcionalidade de ACL e de verificaτπo de acesso, que podem ser usados para controlar explicitamente o acesso de clientes remotos a recursos ou dados do sistema e definidos pelo usußrio. Esses objetos auxiliares sπo fornecidos pelo objeto do sistema CLSID_DCOMAccessControl, que implementa a interface IAccessControl.
A interface IAccessControl deve ser usada para gerenciar permiss⌡es de seguranτa por programaτπo sempre que a portabilidade entre o Windows 95/98 e o Windows NT for um problema. O objeto CLSID_DCOMAccessControl estß disponφvel em todas as vers⌡es do DCOM95 e no Windows NT 4.0 SP2 ou posterior. Para obter mais detalhes sobre IAccessControl, consulte a documentaτπo da plataforma SDK.
Seguranτa para iniciar e de acesso
Nπo hß suporte para o controle de quem pode iniciar o c≤digo servidor-classe no DCOM95, porque nπo hß suporte para iniciar servidores. Os servidores/classes jß devem estar em execuτπo para que os clientes remotos conectem-se a eles e usem seus serviτos. O DCOM95 dß suporte α capacidade de conectar-se a classes/servidores jß em execuτπo. Hß suporte para a seguranτa de acesso atravΘs da chave do Registro \APPID\{.}\AccessPermissions e ajuste atravΘs da ferramenta
DCOMCNFG ou durante a instalaτπo ou configuraτπo do c≤digo do servidor. Usußrios nπo-autenticados poderπo usar servidores se vocΩ configurar a classe para que dΩ suporte a conex⌡es nπo-autenticadas (atravΘs de ferramentas de configuraτπo estßticas ou dinamicamente via funτπo CoInitializeSecurity). VocΩ tambΘm pode compilar ACLs arbitrßrias para definir quais usußrios e grupos podem acessar serviτos especφficos.
Nφveis de autenticaτπo
Os clientes DCOM95 podem fazer chamadas DCOM usando qualquer nφvel de autenticaτπo. Os servidores ou clientes DCOM95 que estejam recebendo retornos de chamada podem aceitar somente chamadas DCOM usando os nφveis de autenticaτπo RPC_C_AUTHN_LEVEL_NONE ou RPC_C_AUTHN_LEVEL_CONNECT.
Transportes
O DCOM95 dß suporte somente a conectividade TCP. Se vocΩ nπo tiver o protocolo
TCP/IP instalado, o DCOM95 nπo poderß dar suporte a COM em todas as mßquinas.
Configuraτ⌡es do Registro
As seguintes chaves do Registro encontradas em
HKEY_LOCAL_MACHINE\Software\Microsoft\OLE estπo estabelecidas pelo DCOM95:
EnableDCOM (valor padrπo = "Y"). Ativa o DCOM nesta mßquina.
Quando definido como "N", a mßquina fica impedida de conectar-se a ou ativar objetos ou mßquinas remotas e as mßquinas remotas nπo conseguem conectar-se a objetos na mßquina local. A definiτπo deste valor como "Y" ativa a conectividade como um cliente para objetos remotos(quando EnableRemoteConnect='N', conforme explicado abaixo) ou a conectividade cliente/servidor total (quando EnableRemoteConnect='Y', conforme explicado abaixo).
EnableRemoteConnect (valor padrπo = "N"). Ativa servidores COM para dar suporte a clientes remotos. Quando este valor estß definido como "Y", as referΩncias a interfaces em objetos locais podem ser passadas a clientes remotos e esses clientes podem conectar-se a objetos em execuτπo. Quando este valor estß definido como "N", esta mßquina pode conectar-se a objetos remotos, mas nπo pode atuar como um servidor: a mßquina fica impedida de conectar-se a objetos em execuτπo.
AlΘm disso, a seguinte chave do Registro Θ encontrada em
ContΘm o n·mero de versπo do DCOM95 no formato "a,b,c,d".
Este valor pode ser usado pelo Internet Component Download para determinar se o DCOM95 estß instalado. Este valor Θ adicionado ao Registro durante a instalaτπo e nπo deve ser alterado.
Usando o Windows 95 como um host do servidor remoto
O Windows 95 pode ser um host do servidor remoto, com as seguintes advertΩncias:
* Nπo hß recurso para iniciar. O processo do servidor jß deve estar em execuτπo para que um cliente possa conectar-se a ele.
* Se forem necessßrias conex⌡es seguras, o servidor (e, no caso de retornos de chamada, o cliente) deve ter controle de acesso em nφvel de usußrio com o nome de um provedor de seguranτa definido.
* O valor do Registro "EnableRemoteConnect" deve ser definido como "Y".
O DCOM95 foi testado mais extensivamente usando o provedor de seguranτa no domφnio do Windows NT. VocΩ pode encontrar problemas usando outros provedores de seguranτa.
Para estabelecer o controle de acesso em nφvel de usußrio, vocΩ deve ter o Filesec.vxd instalado. Este arquivo geralmente Θ instalado no Windows 95 quando vocΩ instala o compartilhamento de arquivos e impressoras.
Para ativar o controle de acesso em nφvel de usußrio, abra a caixa de dißlogo Rede no Painel de controle, clique na guia Controle de acesso, marque a caixa
Controle de acesso em nφvel de usußrio e digite o nome de seu domφnio de seguranτa. Isso pode afetar o modo como vocΩ atualmente compartilhas pastas na rede a partir de seu computador; consulte a documentaτπo on-line para obter mais detalhes. Se nπo houver uma guia Controle de acesso no painel de controle de configuraτπo de rede, serß necessßrio instalar um serviτo de cliente de rede. Clique em Clientes de rede, configurando a entrada no φndice da Ajuda on-line para obter informaτ⌡es sobre a instalaτπo de um cliente de rede.
V. Redistribuiτπo
-----------------
Para obter informaτ⌡es sobre a redistribuiτπo do DCOM95, reveja as diretrizes de redistribuiτπo contidas no contrato de licenτa de usußrio final(license.txt).
VI. Suporte e recursos
-----------------------
O suporte gratuito Θ oferecido por um perφodo de 90 (noventa) dias, contados a partir da sua primeira chamada para o suporte tΘcnico. Passado este prazo, vocΩ poderß optar por outras modalidades de suporte, de acordo com as suas necessidades. O Suporte Padrπo Microsoft funciona de segunda α sexta-feira, de 8:00 αs 20:00 horas, exceto nos feriados, pelo telefone (011) 5506-8087 ou fax (011) 5506-7621.
Fax Automßtico
VocΩ pode receber automaticamente as respostas tΘcnicas por fax. O Fax Automßtico funciona 24 horas por dia, 7 dias por semana, pelo telefone (011) 5506-8506.
BBS (Bulletin Board Service) Microsoft
AtravΘs da BBS, a Microsoft coloca α disposiτπo dos usußrios os drivers de impressora, atualizaτ⌡es de sistemas operacionais e aplicativos. Para acessar a BBS Microsoft, entre em contato pelo telefone (011) 5506-1234.
Suporte On-line
O Suporte On-line Θ mais uma ferramenta que vai ajudß-lo a encontrar, de forma rßpida e fßcil, as respostas para suas d·vidas sobre os produtos Microsoft. VocΩ s≤ precisa colocar uma palavra-chave e iniciar a pesquisa. Todos os artigos em portuguΩs relacionados α palavra-chave selecionada serπo listados para que vocΩ possa consultß-los.
Acesse o nosso Suporte On-line no endereτo http://www.microsoft.com/brasil/suporteonline/
Internet
A Microsoft disponibiliza, via Internet, o Suporte Web Microsoft na World Wide Web (WWW), colocando tΘcnicos α sua disposiτπo para auxiliß-lo a esclarecer suas d·vidas tΘcnicas dentro de um prazo de 48 horas, exceto nos feriados e fins de semana.
Acesse o Suporte Web Microsoft na Internet atravΘs do endereτo http://www.microsoft.com/brasil/suporte
Para obter informaτ⌡es mais detalhadas sobre os Serviτos de Suporte da Microsoft, selecione o comando 'Sobre o <aplicativo>' no menu 'Ajuda' e clique em 'Suporte tΘcnico'.
VII. Listagem de arquivos
----------------------
Esta tabela lista os n·meros de versπo dos arquivos distribuφdos com o
DCOM95.
oleaut32.dll 2.40.4275
secur32.dll 4.10.1999
compobj.dll 2.3.2
ole2.dll 2.3.2
ole32.dll 4.71.2900
olecnv32.dll 4.71.2900
olethk32.dll 4.71.2900
rpcltc1.dll 4.71.2900
rpcltc5.dll 4.71.2900
rpcltccm.dll 4.71.2900
rpclts5.dll 4.71.2900
rpcltscm.dll 4.71.2900
rpcns4.dll 4.71.2900
rpcrt4.dll 4.71.2900
rpcss.exe 4.71.2900
storage.dll 2.3.2
stdole2.tlb 2.40.4275
stdole32.tlb 2.1
imagehlp.dll 4.00
dllhost.exe 4.71.2900
comcat.dll 5.0
iprop.dll 4.00
rpcmqcl.dll 4.71.2900
rpcmqsvr.dll 4.71.2900
olepro32.dll 5.0.4275
asycfilt.dll 2.40.4275
dcom2w98.dll 2.10.35.35
Esta tabela lista os n·meros de versπo dos arquivos distribuφdos com o
